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ABSTRACT 

Disconnected networks arise in environments where stable, well- 
connected infrastructure connectivity is not ubiquitous. In practice, 
these arise particularly in mobile systems, where the connectivity 
can be achieved through short-range, pair-wise contacts between 
mobile nodes. Information-centric Networking provides a high- 
level framework through which many different systems for discon¬ 
nected networking can be understood. In this paper, we present a 
system built on top of the ICN abstraction that allows interactive 
web applications to be developed and deployed in disconnected 
networks. We describe our system and protocol design, validate 
its operation using simulations, and report on our implementation 
including adaptations of six existing apps into web applications ca¬ 
pable of being deployed in disconnected networks. 


1. INTRODUCTION 

Information-centric Networking (ICN) is a paradigm that shifts 
the focus from the communicating end-points to the content of 
the communication instead ||^. The argument for designing ICNs 
arises from the observation that in most of the real world commu¬ 
nication it is the content, or information, that is important, not who 
is communicating with whom | [55) . Therefore, ICNs name and 
operate on named data objects or information, rather than on the 
network end-points. This logically decouples the senders and re¬ 
ceivers, which allows for natural in-network caching (content can 
be stored anywhere) and multi-party communication (content can 
be replicated to many receivers). Using the ICN abstraction that 
more closely matches the reality of how the communications are 
structured allows for more efficient networks to be designed and 
deployed. This in turn may enable novel services to be designed 
that would have been too inefficient to be realized on end-point- 
centric architectures. 

What the ICN approach cannot do, is to abstract away the fun¬ 
damental reality of the underlying physical infrastructure from the 
applications running on top of it. In well-connected physical in¬ 
frastructures, it is possible to layer IP over ICN to transparently 
support all the existing Internet applications and their implementa¬ 
tions, while gaining benefits from the intrinsic caching and multi¬ 
casting features of ICNs p4) . However, this requires the network 
to support low latency interactions on a global scale, since that is 
the underlying assumption in the design of the transport and ap¬ 
plication protocols on top of IP. When physical reality breaks this 
assumption, e.g., when the network is composed of short pair-wise 
contacts between nearby mobile nodes, dissemination strategy of 
ICN must change. Typically a space path oriented dissemination 
is replaced with a space-time path oriented one, or in other words, 
packet switching is replaced with store-carry-forward dissemina¬ 


tion. We refer to these as disconnected ICNs, which arise particu¬ 
larly frequently in mobile systems. 

The opportunistic and delay-tolerant networking communities 
have produced many solutions to these scenarios, including Hag- 
gle (^1^1^, SCAMPI (^, IBR-DTN (Tg, and PodNet 
[^ . These designs have tended to naturally converge towards the 
ICN principles, but there are also designs explicitly starting from 
the ICN principles, such as Netinf CD The underlying phys¬ 
ical network may be composed purely of opportunistic contacts 
between mobile nodes, or may include lightweight infrastructure, 
or throwboxes such as the Liberouter system pS) . Unlike 
well-connected ICNs, disconnected ICNs require explicit adapta¬ 
tions and redesigns of the applications. This is due to the complete 
break down of assumptions about reachability and latency that are 
fundamental to classic application designs. 

In this paper, we focus on bringing the most widely used clas¬ 
sic Internet application, the Web, into disconnected ICNs. We can 
identify two distinct types of sites in today’s Web: 1) content based 
sites, and 2) web applications. The former are sites composed of 
content that is static at any given point of time. Examples of these 
are company or institution websites, which rarely change, and also 
websites with frequent content changes like news sites. These static 
sites are easy to conceptually map onto ICN architectures, by treat¬ 
ing the entire site with all of its resources (HTML, CSS, IS, im¬ 
ages) as content items named by their URLs. Bringing these types 
of web sites into disconnected ICNs has been demonstrated in the 
past 140) . 

However, many Web sites today are not composed of static con¬ 
tent, but are more accurately characterized as Web Applications. 
These are sites designed to let users perform various functions, 
tasks and activities, rather than simply presenting static content 
to them. Many of the most popular Web sites of today fall into 
this category, e.g., social networking (Facebook, Google-i-), photo 
sharing (Instagram, Snapchat), and messaging (Twitter). They are 
effectively equivalent to native applications, except they happen to 
execute inside a Web browser context. 

These types of web sites do not map semantically cleanly onto 
ICN architectures the same way as the static content based sites do. 
This is because a key feature of these web applications is reliance 
on back-end services reachable via the Internet, and typically ex¬ 
posed via RESTful APIs. The API interactions require stable and 
low-latency connectivity between the browser and the back-end, 
which is only possible in well-connected networks. 

Our contribution in this paper is to present a system design and 
implementation that enables web applications to be developed for, 
and deployed in, disconnected ICNs. The solution is based on 
leveraging three key concepts: 1) a throwbox based physical net¬ 
work, and 2) the caching, and 3) the multicast dissemination nat- 
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Figure 1: Overview of the Liberouter based system model. 


urally performed by the disconnected ICNs. While not every dis¬ 
connected ICN design has these characteristics, many practically 
deployable systems do. 

In particular, we extend our previous throwbox design, the Liber- 
outers, to include a framework that can serve interactive web appli¬ 
cations to nearby clients through standard, unmodified web browsers. 
We show how to bundle together the data and the logic that com¬ 
prises the classic web application. These bundles are then spread 
in the network through the caching and multicasting mechanisms 
inherent in the operation of disconnected ICNs. Any instance of 
our framework that receives a copy of a bundle can then use con¬ 
tained data and logic to instantiate the web application accessible 
to locally connected clients. 

Our results show that it is possible to adapt the traditional cen¬ 
tralized web application model to disconnected ICNs by combin¬ 
ing pieces of content and the related logic in a single message. 
We further demonstrate the practicality and generality of our sys¬ 
tem design through a real implementation on two different discon¬ 
nected networking middlewares. Finally, we show through simula¬ 
tions that the solution does not incur large enough overheads that it 
would adversely impact the content dissemination done by ICN. 

Next, in Section]^ we describe our system model and archi¬ 
tecture at a high level, and provide a justification for our message 
based approach from a distributed systems perspective. We then 
lay out the detailed design of our framework in Section and its 
proof-of-concept implementation, including integration with two 
different disconnected ICN platforms, in Sections and We 
demonstrate the use of the platform by adapting a number of ex¬ 
isting applications, including the Google People Finder web appli¬ 
cation, to use our framework in SectionFinally, we show a sim¬ 
ulation based validation of our system design in Section review 
the related work in Section [8] and conclude in Section 


2. SYSTEM MODEL 

As described previously, our approach extends a Liberouter based 
opportunistic networking system. Figure shows the high level 
model of the system. It is composed of opportunistic infrastruc¬ 
ture nodes that act as access points {Liberouter AP in the figure) to 
which nearby clients can connect. Our model considers two types 
of users: 1) native users whose devices have native ICN support 
and applications (bottom left), and 2) web users who are assumed 
to only run an unmodified web browser (bottom right). This leads 
to native ICN and HTTP links respectively. The application inter¬ 
actions that we aim to enable through our framework are between 



Figure 2: a) Equilibration in a distributed system, b) Latency- 
partition duality. 


the web users and native ICN users. We extend the functionality of 
the lightweight Liberouter devices by adding a Web App Interac¬ 
tion Framework between a local ICN networking layer and a web 
portal. The interactions are bi-directional, allowing the web users 
to both consume and produce content for the existing ICN applica¬ 
tions. 

We will next explain the underlying messaging model from a 
distributed systems perspective in Section [TT] and show how our 
system can be understood from the applications’ viewpoint in Sec¬ 
tion [2]2 

2.1 Messaging Model 

The messaging model that we use can be derived from the fun¬ 
damental properties of distributed systems and opportunistic store- 
carry-forward networks. In general, distributed systems are de¬ 
signed to establish a globally consistent state in multiple indepen¬ 
dent entities through message exchanges. This is shown in Fig¬ 
ure 01 where a state change Sq Si in N 2 is propagated to the 
other entities in the system through messaging. This process takes 
place from time Ti to T3, which is the time it takes for the message 
to propagate to all other entities. During this time the system is 
in a globally inconsistent state, and the process of reaching a con¬ 
sistent state is called equilibration. The fundamental problem of 
distributed systems design is to ensure that the equilibration pro¬ 
cess results in globally consistent states in the face of concurrent 
state transitions in the entities. 

The CAP conjecture ||6j is a useful tool for thinking about the 
fundamental properties of distributed systems. The major insight 
to be gained from CAP is that when facing partitions (P), a dis¬ 
tributed system design can trade availability (A) against consis¬ 
tency (C). Strict consistency can be enforced in some systems by a 
global locking mechanisms, but it leads to no availability when the 
system is partitioned and the lock cannot be acquired. Consensus 
mechanisms employing quorums alleviate this by requiring only a 
subset of the entities to agree on state changes. This effectively 
leads to the larger part of a partitioned system to remain available, 
at the expense of the other part having no availability and an in¬ 
consistent view of the global state. Mechanisms such as using soft 
state and caches closer to the clients ensure availability in the case 
of partitions, but can lead to a globally inconsistent state and prob¬ 
lems when trying to reconcile inconsistent states after a partition 
ends. This essentially buys more availability at the cost of going 
from strict consistency to eventual consistency. In all cases, a key 
assumption in the design of both centralized and peer-to-peer dis¬ 
tributed systems is that partitions are transient phenomena, and the 
system can eventually reach a consistent and available state. 


2 



























An important observation regarding the CAP formulation is that 
partitioning is tightly coupled with latency, forming a type of latency- 
partition duality. This is because in the absence of explicit knowl¬ 
edge about the network, a partition is not distinguishable from a 
long delay, as illustrated in Figure S’- This forces system de¬ 
signs to use delay thresholds as indicators for partitions, which in 
turn makes implicit assumptions about the information propagation 
speed in the network. In particular, it assumes that latencies are 
in the order of user-acceptable application level transaction times; 
an assumption that holds in well-connected infrastructure networks 
where failures are transient conditions. 

Disconnected store-carry-forward networks are composed of pair¬ 
wise contacts between mobile nodes. This means that the informa¬ 
tion propagation latency is limited primarily by the inter-contact 
times between the mobile nodes, and not by the speed of light (and 
queueing) as in well-connected networks. Combining this with the 
latency-partition duality, such systems can be seen as being in a 
constant state of partitioning, causing the breakdown of the under¬ 
lying assumptions of the mechanisms used to maintain consistency 
properties in “classical” distributed systems. Another way to state 
this is that the time for a distributed system built on such a network 
to equilibrate can be orders of magnitude larger (even unbounded) 
than the time scales required by meaningful application semantics. 
I.e., changes are made much faster than the time it takes to reach 
an equilibrium. 

This leads to the need to abandon the idea of global consistency, 
and instead build distributed systems that are inconsistent by de- 
sigifl A system that is inconsistent by design requires each entity 
to build their own locally consistent view of the world based on 
their own set of observations. In concrete terms, it is the client 
software’s responsibility to create a locally consistent view or state 
from the (random) set of messages that it has received. Another 
way to state this is that the system enforces only local invariants. 

Messaging is used as a way to transition the state of the entities 
in distributed systems. This can be written as m : A{Sx, Sx+i), 
where S is the state of the system. In other words, a message con¬ 
tains the difference between the two states, which the recipient can 
apply to its state Sx to transition to the state Sx+i- This has two 
major implications: 1) the recipient must be in the given state Sx or 
the message is useless, and 2) as a result of applying the message, 
the recipient will be in the precise state Sx+i- This makes sense in 
distributed systems that are designed to (periodically) reach glob¬ 
ally consistent states. 

The above messaging model does not make sense in distributed 
systems that are inconsistent by design, including opportunistic 
networks. First, the messages should be applicable in any state, 
otherwise in a system where every entity is potentially in a different 
state, most messages would be useless. Second, since the system is 
not designed to ever reach a globally consistent state, the messages 
do not need to result in all the recipients moving to the same state, 
just some locally consistent state. 

This leads to a different messaging model, where each message 
will cause a different state transition from one locally consistent 
state to another in each receiving entity. This can be written as 
N{m) : Sn ^ Sn'^ where node N applies message m to transi¬ 
tion from the locally consistent state Sn to another locally consis¬ 
tent state Sn' • We can observe that it must be possible to apply the 
transition from any state, including the empty state, into some lo¬ 
cally consistent state; N{m) : ^ ^ Sn- This is typically expressed 


^ There are inconsistent-by-design distributed systems built for 
well-connected networks too, such as the git distributed source 
code management system. 
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Figure 3: Bundling content and logic to enable distribution in a 
disconnected ICN. 


in opportunistic and delay-tolerant networking as messages being 
self-contained and semantically meaningful. 

It is this fundamental property of self-contained messages that 
we exploit in building our framework. This messaging model fur¬ 
ther implies that the network will have a large number of these mes¬ 
sages (i.e., content), which can be interpreted independently of any 
specific application state. However, the applications themselves are 
still required in order to participate in the system. The key idea of 
our framework is to ship minimal, generic application logic along 
with the messages, which allows any node a degree of interaction 
with the system (e.g., view, respond and send) without requiring 
the specific native application. 

2.2 Application Model 

Traditional web applications are built around a centralized client- 
server model, as shown on the left of Figure In this model, 
all application data are stored in the central server, along with the 
back-end logic that controls interactions with that data. The server 
exposes an interface towards the clients, typically through a REST- 
ful API. The clients run the web application front-end logic inside a 
browser as a collection of JavaScript libraries and code, which calls 
the back-end services through the API. The front-end logic fetches 
the relevant pieces of data from the back-end for presentation to 
the user, and sends back the user’s data for storage in the central 
database and for sharing with other clients. 

The fundamental underlying assumption in the client-server model 
is the existence of a stable and fast network connecting the clients 
to the server. This assumption is satisfied by the Internet in most 
of existing deployments, and can be equally satisfied by a well- 
connected ICN. However, ICNs can also be deployed in discon¬ 
nected environments, where the dissemination strategy is build around 
exploiting short-lived one-to-one contacts between devices. In such 
a dissemination mode, the client-server approach becomes imprac¬ 
tical, as it is generally not possible to support the low-latency end- 
to-end interactions required by the back-end API. 

To enable web-browser based applications in disconnected ICNs, 
as shown in the right of Figure we need to deal with two funda¬ 
mental aspects of the web applications: data and logic. 

First, the data of the application cannot be stored in a central¬ 
ized database, because reaching such a database with a reasonable 
latency is generally not possible. Solving this in ICN is straight 
forward since the originator of the data can simply publish content 
into the network as self-contained, semantically meaningful mes¬ 
sages, which become accessible to other nodes without the need 
for a centralized database. For example, a social networking ap¬ 
plication does not need to get an image posted by the user sent to 
a data center on another continent, but can simply disseminate it 
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directly to nearby peers. Consequently, we go from a centralized 
database into a distributed storage of pieces of application data us¬ 
ing the resources available directly in the disconnected ICN. 

Second, just getting access to data does not solve the whole issue. 
We must also be able to run logic to generate presentation of data 
to display to the user, and to generate new data into the network 
in response to user actions. We solve this by attaching the logic to 
each message along with the data. This ensures that data and logic 
essentially share fate - If there is no data available, then there is 
no need for the application logic to present the data; if there is no 
application available, then there is no value in having data since it 
cannot be presented. This bundling of data and logic is shown in 
the middle of Figure 

Attaching the full front-end application and related back-end logic 
to every piece of application data would result in large overheads. 
We therefore create an abstraction of the application logic which is 
split into two parts: 1) a generic application model, which defines 
the states and transitions of the application, and which is imple¬ 
mented by the Liberouter device running the framework. In this 
paper we use a simple summary/detail model where the application 
has two main states or views; a list of summaries of each message, 
where the user can select a particular message to get a detail view of 
that message. Different generic models could be defined and each 
message could indicate which model is the best fit to present it. 2) 
functions that are executed at different points in the generic 
application flow to generate the particular view of, or the action on, 
a message. This is the logic that is carried with each message and 
which is defined by the application developer as scripts. 

3. WEB APP INTERACTION FRAMEWORK 

We now turn to a detailed description of the framework. We be¬ 
gin with the description of the framework and its functionality at a 
conceptual level (Section IM}- Extending message with presenta¬ 
tion and interaction logic transformations by shipping them as meta 
data is explained in Section [T^ Section [T^ provides a detailed de¬ 
scription of the framework including functionality and interactions 
between framework components. Section [3^ describes the process 
of bootstrapping web applications. Finally in Section [T5] we dis¬ 
cuss security implication for the framework design. 

3.1 Conceptual Model 

Recall from Section|^that self-contained and semantically mean- 
ingful messages are the foundation of our framework design. Our 
goals are to: (1) enable generation and presentation of content by 
web browsers through the framework and (2) provide interoperabil¬ 
ity between native applications and their web equivalents. We could 
easily achieve content presentation by embedding HTML describ¬ 
ing content into a message. But this would not allow for generation 
of new content and would tightly couple the application state with 
the message interpretation. Therefore, we choose a more general 
approach. In the rest of paper, we use message to refer to the trans¬ 
port unit in an underlying ICN and content as general data associ¬ 
ated with an application. 

The interpretation of content can be seen as a transformation 
of a set of messages into a view rendered by a web browser, i.e., 
generation of an HTML page from a set of messages. There are 
two aspects to this transformation: 1) an individual message must 
be transformed into an HTML view, and 2) these individual views 
must be composed into a coherent application view. For example, a 
photo sharing application would be composed of a transformation 
of individual messages into, e.g., thumbnail views, and a compo¬ 
sition of those thumbnails into an application view, e.g., list sorted 
by the date. 
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Figure 4: Processing of messages for content extraction and pre¬ 
sentation in web browsers. 


For the first aspect, we define two transformations: message 
summary and message presentation. The message summary trans¬ 
formation generates a concise view of the message, suitable for 
inclusion in a listing of a large number of messages. The message 
presentation transformation generates a detailed view of the mes¬ 
sage, intended to be displayed on its own to a user who is interested 
in the message content. Both transformations are pure functions 
that take as input the message and generate the presentation view 
as output (i.e., HTML code). The transformations are message type 
and application dependent, and are expected to be included in the 
message itself by the original generating application. 

As messages are self-contained, the message transformations alone 
already provide a useful view into the messages. However, in many 
applications there may be further requirements on the display of 
sets of messages. For example, a message board application should 
list its messages in time order and possibly threaded by a topic. 
This corresponds to an application level logic which would nor¬ 
mally be implemented by the native clients. To this end we define 
application presenter transformation. 

The application presenter transformation is similar to the mes¬ 
sage transformation in that it is a function that maps a set of inputs 
into an HTML view to be displayed via a web browser. As input, 
they take a set of messages (e.g., all messages belonging to a par¬ 
ticular application), and optionally some set of state generated by 
a previously run presenter. For example, a forum application could 
have one application presenter transformation that processes all fo¬ 
rum messages and generates a list of topics. When the user selects a 
topic, another application presenter transformation would generate 
a list of all messages within the topic. In general, each application 
can have an arbitrary number of linked application presenter trans¬ 
formations that can call each other. Figure [^illustrates the whole 
process of building complex application level web views based on 
transformations included in application messages. 

The generation of messages can take two forms: generating new 
messages, or replying to an existing message. Both take as input 
a predefined set of values and compose a message, which is then 
injected into the network by the framework. The difference is that 
the reply transformation also gets as a parameter the message to 
which the user is responding. 
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Table 1: Web Message Interaction Format summary 


Table 2: Inferred HTML tags for given contentType values 
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Figure 5: System components and their interaction. 


3.2 Shipping App Logic along with Messages 

To enable bundling of presentation and interaction logic with 
messages, we propose to attach transformations to messages as 
meta data in the key-value format. We define five basic keys, and 
each key corresponds to the specific transformation. The appSum- 
mary key contains the application presenter transformation. The 
message level transformations are contained in summary and pre¬ 
sentation keys. Finally, for generating new content, new and reply 
keys carry appropriate transformations. 

There are also additional keys that help the framework to present 
content in the web browser. The contentType key indicates type of 
data contained in the message (e.g., if an item carries a photo, con¬ 
tentType should have “image” value). For simple items compris¬ 
ing only data of one type, the framework may take advantage of 
the contentType key, and provide a simplified interpretation of the 
message content (e.g., by taking a thumbnail for the “image” con¬ 
tentType). Other keys defined are: description, service, icon. The 
description provides a short text summary of the message content 
(e.g., short comment on the location of photo shot). The service 
key maps the message to the application name and icon contains 
an application icon. Table [^provides an overview of defined meta 
data items. 

3.3 Framework Design 

The framework comprises four main components, namely Con¬ 
tent Processor, Content Generator, Web Server and Sandbox. It 
also uses a message queue and a shared memory for inter-process 
communication. Finally, to allow for independence of the frame¬ 
work from an underlying ICN system, the framework defines also 
ICN Communicator which (1) tracks changes of messages in the 
ICN cache and (2) acts as an adapter of message format for the 
underlying system. Figure shows an overview of the framework 
architecture. 
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Content Processor is notified by ICN Communicator about changes 
in the ICN cache. If a new message is reported by ICN Communica¬ 
tor, Content Processor extracts meta data contained inside the mes¬ 
sage and writes them into the shared memory. After that it checks if 
extracted meta data contain transformations and if yes, it asks Sand¬ 
box to securely execute all contained transformations and writes 
their outputs into the shared memory. Details of Sandbox design 
are explained in the Section [33| Execution of all transformations 
at this stage allows to have message presentation data cached if the 
web user wants to see them in the future, greatly improving his user 
experience. However, if meta data do not contain transformations. 
Content Processor provides a simplified presentation of message 
content, which is based on the value of the contentType key. Tablej^ 
describes mappings between the contentType value and the HTML 
tag for simplified content presentation.Finally, Content Processor 
notifies Web Server via the message queue about the new message 
that has appeared in the ICN cache by giving Web Server pointer 
in the shared memory to the item’s data for access. Similarly, if 
removal of an existing message is reported by ICN Communicator, 
Content Processor removes its details from the shared memory and 
notifies Web Server about it. 

Web Server is responsible for: (1) presenting stored message 
content to the user, and (2) handling requests to create new con¬ 
tent coming from the user. It realizes message content presentation 
by implementing the generic web application model. It is build of 
a set of generic template views, which are filled with appropriate 
transformation outputs depending on type of view presented to the 
user. For example, if user wants to see whole content belonging to 
a particular application, Web Server fills template with the output 
of the application presenter transformation. For a request to gen¬ 
erate new content, Web Server presents user with an HTML form 
(result of the newireply transformation) that has to be filled in with 
new item details. The user submits the form to Web Server which 
validates it, and if correct it passes it to Content Generator via the 
message queue. 

Content Generator component listens for new content request 
from the message queue. Upon its reception, it creates a new mes¬ 
sage based on data from the form and the shared memory, after that 
it moves the newly created item into the ICN cache. 

3.4 Bootstrapping Applications and Nodes 

So far, in our design, transformations are always shipped along 
with the message. This ensures compatibility between content and 
the application logic. However, it also implies that web users can 
generate content for a web application only if Liberouter they con¬ 
nect to has already stored a message of this application. In practice, 
this means that every web application must be bootstrapped from 
its native equivalent. To overcome this limitation, we take two fur¬ 
ther steps: (1) distribute native applications within the framework 
to increase availability of native applications in ICN, and, more 
importantly, (2) allow creation of initial content from the web ap¬ 
plications. 
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Recall that a native application is essentially a structured binary 
content (i.e., an executable plus auxiliary data). As such, it can be 
wrapped up inside a message and distributed across ICN to become 
accessible via a disconnected “app store” 

To address (1), the framework offers the disconnected “app store” 
functionality by making all native applications available to web 
users for download via the web browser - if a received message 
has contentType value of “app”, Content Processor extracts an exe¬ 
cutable contained inside it and puts it inside the Web Server public 
directory, (see Figurej^. For (2), we also include transformations 
in messages used to distribute native applications. A user visiting 
Liberouter can then not just choose to install a native version of an 
application, but also to create new content using just a web version 
of the application. 

3.5 Security considerations 

To guarantee robust and secure operation of the framework, our 
security considerations focus on four issues: (1) secure execution of 
a transformation, (2) message authenticity, (3) encrypted message 
access and (4) impact of communication mode on privacy. The first 
requirement is the most important one, as insecure execution of a 
malicious transformation may result in framework operation mal¬ 
function and unauthorized access to ICN cache. In a disconnected 
environment, access to an authentication server cannot be taken for 
granted, thus the framework must provide functionality for verifi¬ 
cation of message authenticity. 

Threat model and assumptions. We are concerned with threats 
that an adversary: (1) disrupts framework/ICN functionality by 
executing a malicious code and (2) impersonates another user by 
sending a message that masquerades its originator for another user. 
Our threat model assumes also: (1) presence of basic Linux plat¬ 
form security mechanisms and (2) presence of a disconnected pub¬ 
lic key distribution (PKI) system (57) which assigns a public key to 
an identifier of message originator in ICN. Examples of such PKI 
systems are SocialKeys and PeerShare p4) . 

Secure execution of transformations. Execution of transforma¬ 
tions of unknown origin poses a serious threat to the secure func¬ 
tioning of the framework. The malicious transformation may in¬ 
clude system calls causing disruption of the framework operation 
and possibly even whole ICN (e.g., the transformation switches off 
all network interfaces). The other set of threats comes from unau¬ 
thorized content access. They include pollution of content by gen¬ 
eration of fake messages, deletion of other messages and access to 
information contained in other messages. This threat model moti¬ 
vates implementation of the file system level isolation and the sys¬ 
tem call filtering. Eile system level isolation constrains the transfor¬ 
mation to access only data contained inside the message and parts 
of the shared memory that are related to it. As system calls are still 
available to the transformation (via system libraries), the system 
call filtering must prevent invocation of any system calls other than 
I/O operations on message content to which the transformation be¬ 
longs (see section|^for details). Since transformation access to file 
system is constrained and it cannot invoke system calls other than 
file system I/O, security requirements of transformation execution 
are fulfilled. 

Message authenticity. We address the threat of another user imper¬ 
sonation by providing mechanisms to verify message authenticity. 
It requires that message is signed by its originator. Verification of 
message authenticity can be realized on the framework side, or in 
the web browser. Eor the former, the framework itself verifies the 
signature of the message using the public key available in the ICN 
cache. The browser side verification assumes that the public key is 


accessible in the browser for the web application (e.g., it is present 
in HTML5 local storage). Section [^provides implementation de¬ 
tails. 

Encrypted message access]^ In the framework design, we make 
the assumption that content carried inside messages is unencrypted, 
thus easily accessible by the framework. However, we argue that 
web users experience can be further enriched by providing them 
also access to encrypted content. To do this, we assume availability 
of cryptographic keys in web users browsers which are either deliv¬ 
ered via some key distribution system, or derived by web users by 
means of Password-based Cryptography p^ . Since encrypted con¬ 
tent should be accessible only to users that have an appropriate key, 
it must be decrypted inside the browser (using either Web Cryp¬ 
tography API, or a specialized JavaScript module fetched from the 
framework). Einally, the transformations of decrypted messages 
must also be executed inside the browser (thus they must be writ¬ 
ten in JavaScript), so that they can be directly displayed to the web 
user without the necessity to interact with the framework. 

Communication mode and privacy considerations. Current frame¬ 
work design assumes that all messages stored in the ICN cache 
should be accessible for all users. This assumption holds well 
for all applications in which users do not target their content at a 
(closed set of) recipient(s), but rather share it openly. Thus, all 
users can read all messages for the group using the framework. On 
the other hand, for applications targeting their content at specific 
recipients, the framework must not give access to their messages 
to the unauthorized users, as it would violate user’s privacy. The 
same problem holds for granting users access to encrypted mes¬ 
sages. Eor these group of applications, the current framework needs 
to be modified to support addressing scheme for legacy users. This 
feature can be realised by generating a random endpoint identifier 
on the first connection to the framework and storing it persistently 
in the web browser as a cookie. As a result, the framework may use 
cookie to identify the legacy user and grant access only to his/her 
private messages. 

4. IMPLEMENTATION 

We now turn to the implementation details. We first cover im¬ 
plementation of core framework components, followed by security 
components details, which are described separately due to their 
high complexity. After that we explain web application transfor¬ 
mations and finally conclude this part with performance evaluation 
of the framework. 

Core framework. We implemented the framework as the combi¬ 
nation of four applications, namely Content Processor, Sandbox, 
Web Server and Content Generator. Content Processor component 
is developed in standard Java. It monitors updates to the ICN cache 
by: (1) parsing meta data of newly received messages, and storing 
them as a hash map inside RediQ (acting as the shared memory), 
and (2) clearing Redis of data removed from the cache. Textual 
meta data objects included inside messages are stored directly in 
Redis, while binary objects are written to the framework persistent 
storage, and only their access paths are stored in Redis. Content 
Processor uses Redis queue to notify the Web Server about changes 
in the ICN cache. 

Web Server component is implemented as the Node.js applica¬ 
tion. It implements the generic web application model as a set 
of HTML templates with empty J/vs, which are filled with script 

^Implementation of this part is still ongoing. 

^Redis: http://redis.io/ 
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outputs. The HTML template engine is implemented using EJS|^ 
The generic web application model enables new content generation 
for the web users by providing them with an application specific 
HTML form. Web Server validates the filled form and sends it to 
Content Generator using Redis queue. To obtain a good user ex¬ 
perience, Web Server provides real-time content updates by means 
of WebSocket Protocol that is implemented using socket.icj^ 
library. Finally, Web Server provides also “app store” functionality 
by allowing web users to upload their own native applications via 
an HTML form. 

Content Generator is the Java native application that: (1) reads 
a new content request from the message queue sent by Web Server, 

(2) performs application-specific encoding of the new message and 

(3) publishes it to the ICN cache. 
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Figure 6: Screenshot of the framework presenting native oppor¬ 
tunistic applications that can be downloaded on a device and appli¬ 
cations having content stored on it. 


In our implementation there are no constraints on data types that 
can be attached to the message as part of meta data. The only re¬ 
quirement is that if an attached item is a Java serialized class, such 
a message must also carry a “.class", or JAR file implementing 
the class. In such cases, the Content Processor dynamically loads 
attached data, transforms it to jsor^ and stores it in the shared 
memory. 

Security components details. Recall from the Section [T5] that our 
threat model calls for implementation of the file system level iso¬ 
lation and the system call filtering. The framework realizes the 
file system level isolation by: (1) creating a temporal directory 

"^FJS: http://www.embeddedjs.com 
^Socket.IO: http://socket.io 
son-io: https ://github.com/jdereg/j son-io 


and inserting into it all data carried inside the message and (2) 
isolating other file system resources from the message content (by 
means of chroot call). We realize the system call filtering using 
seccomp-bpf eg- It allows to whitelist a subset of system calls 
that a transformation has a permission to execute |T). Invoking a 
system call that had not been whitelisted causes termination of the 
transformation process. Since the transformation should be given 
access to all meta data carried by the message, our seccomp-bpf 
profile allows the execution of only system calls that open and op¬ 
erate on files. Whole functionality of Sandbox is implemented in 
C. 

Browser side verification of message authenticity requires avail¬ 
ability of a public key in the browser via HTML5 local storage or 
access to device persistent storage (e.g., the File API |[4^). Both of 
these functionalities are supported by all modern browsers. The au¬ 
thenticity verification process is realized fully inside the JavaScript 
code via Web Cryptography API | [4^ . To minimize trust put on 
the framework for verifying message authenticity, it is preferable 
for the user to use browser-side option of verifying authenticity. 
But the framework-side alternative (recall from Section |T5] ) is the 
more realistic option due to poor support of Web Cryptography API 
among the modern browsers (E) 

Web application transformation. The web application transfor¬ 
mations are implemented in Python, and must follow basic trans¬ 
formation design guidelines described in Section|3T] Furthermore, 
to enable access to all meta data related to a particular message, 
the Redis key pointing to a location of item meta data in the shared 
memory is used as the transformation command line argument. In 
order to prevent the transformation from crashing caused by mak¬ 
ing a call to the library that is not available in the framework, the 
framework implements the Python module that checks for presence 
of a non-standard Python library. Consequently, if the non-standard 
library is not available, the transformation can make a fallback to 
a different call. Aiming for simplification of developer task to pro¬ 
vide a good user experience, the framework gives the transforma¬ 
tion access to Boots trafQlibrary, so that the transformation can gen¬ 
erate a sophisticated HTML presentation of content, while content 
itself does not need to carry additional CSS style files as meta data. 

Framework performance evaluation. We evaluated our frame¬ 
work implementation by measuring execution time taken by each 
component to process a single message. We performed experiments 
on Macbook Pro (2.66 GHz Intel Core i7 CPU with 8GB of RAM) 
running OS X 10.10.1 and repeated the experiment 30 times to ob¬ 
tain statistical significance. 

Content Processor and Sandbox are the most resource consum¬ 
ing components (Fig. [^. This is an expected result, as both of 
them perform higher number of I/O operations with the hard disk 
in comparison to other components. In overall, the average execu¬ 
tion time on discovering new message in the cache is about 500ms, 
while generation of a new message takes about 15ms. 

5. SYSTEM INTEGRATION 

The framework is abstracted from the details of the underlying 
caching mechanism through ICN Communicator interface. In the 
simplest case, the operation are purely local filesystem reads and 
writes, and no dissemination happens beyond Liberouter device. 
To enable dissemination beyond the local device, the framework 
can be integrated with some ICN platform, which implements con¬ 
tent spreading between nearby devices. In practice, the framework 
can be integrated with any system which supports shipping meta 

^Bootstrap: http://getbootstrap.com 


7 






Time, ms 


Figure 7: Mean execution time (measured in milliseconds) taken 
by each framework component (logarithmic scale). 


data inside content. To demonstrate this concept in practice, we 
have implemented integration with two disconnected networking 
solutions, SCAMPI and IBR-DTN. In both cases ICN Communi¬ 
cator reads messages directly from the platform cache, and writes 
messages through the respective platform API. 

SCAMPI. Although SCAMPI is designed to be the delay tolerant 
networking (DTN) platform, it meets all requirements of the ICN 
platform. As such, it provides: (1) data cache, (2) publish-subscribe 
functionality and (3) the network layer implementations capable of 
delivering messages based on store-carry-forward networking. It 
is implemented as the middleware that runs on any platform with 
Java support, thus it allows to build an efficient ICN network with 
mobile devices acting as ICN nodes. It also includes a number of 
extensions to support geographically constrained content distribu¬ 
tion p4) , and content search mechanisms. Among existing oppor¬ 
tunistic network routing protocols, only Epidemic p6) and static 
routing are supported. Namespaced metadata key-value pairs can 
be attached to the messages to provide application hints to the un¬ 
derlying networking layer. 

Applications can be developed to use the communication ser¬ 
vices provided by SCAMP I . These applications can either be native 
(Java) applications, or HTML5 web applications. The applications 
can also be distributed by the middleware without requiring a cen¬ 
tralized app store. However, to run the applications, the middleware 
and the application itself must be running on the device. 

Implementation of ICN Communicator for SCAMPI requires: 
(1) developing cache monitor as a directory tracker (SCAMPI im¬ 
plements cache as a set of file system directories) and (2) using 
SCAMP lAppLib library to publish new content to ICN. 

IBR-DTN. IBR-DTN is the DTN platform, similarly to SCAMPI 
working as a middleware. Unlike SCAMPI, it does not provide 
publish-sub scribe functionality, but it is also the data dissemina¬ 
tion system with cache functionality, thus fitting into our scope 
of disconnected environments. It runs on any Linux based oper¬ 
ating system as well as on Android and BeagleBon^ It discovers 

^ http: //beagleboard. org/bone 


and establishes communication links with nearby devices using Wi¬ 
Fi, Wi-Fi Direct |58| and Wireless Personal Access Network(IEEE 
802.15.4) technologies. Like SCAMPI, the IBR-DTN’s de¬ 
sign follows the basic DTNRG architecture |[^|^[^. In addition 
to SCAMPI, it implements also convergence layers for other un¬ 
derlying network technologies (i.e., UDP over IP, IEEE 802.15.4 
LoWPAN). Unlike SCAMPI, IBR-DTN does not offer any appli¬ 
cation level extensions (e.g., content search mechanisms), however, 
in addition to the Epidemic routing, it provides other opportunistic 
network routing protocols, namely PRoPHET pO) and Direct De¬ 
livery routing. 

Applications can be developed for IBR-DTN communication 
service with Java and C-i-i- client libraries currently available to de¬ 
velopers. For other programming languages, developers must write 
their own client libraries to communicate over TCP with middle¬ 
ware services. 

The process of IBR-DTN integration into the framework is iden¬ 
tical to the SCAMPI integration. The only difference is that devel¬ 
opers must replace AppLib with: 1) ibrdtnlib as a Java library, 2) 
libapi for C-i-i- development and 3) ibrdtn-api for Android. 

6. SAMPLE WEB APPLICATIONS 

To build the web version of the existing native application, an 
application developer must implement transformations in Python 
needed in the application. Among all defined transformations, only 
the message summary transformation is necessary, as it allows the 
framework to always interpret the content of the particular message 
independent of presence of other messages belonging to the web 
application (but content generation and application level logic is 
not available then). Developers attach transformations to messages 
using third party software libraries (recall from the Section|^. 

To facilitate development process, we have also implemented a 
simple transformation testing environment. It allows the applica¬ 
tion developer to test correctness of his implementation by: (1) ex¬ 
ecuting the transformation in it and (2) verifying that the HTML 
view generated by the transformation is coherent with the desired 
application design. 

Now we present description of our six web applications. From 
the available SCAMP I applications we have extended GuerrillaPics, 
GuerrillaTags and PeopleFinder, while for the IBR-DTN router we 
enhanced Whisper, Talkie, and ShareBox. As PeopleFinder appli¬ 
cation is the most sophisticated one among these applications, we 
describe it in the Section 6.1. The other applications are described 
in the Section 6.2. 

6.1 PeopleFinder application 

scampi’s version of PeopleFinder is an adaptation of Google 
Person Findeij^ application into disconnected environments. The 
Google’s version of the application has proven its usability in vari¬ 
ous disastrous scenarios starting from 2010 Haiti earthquake. The 
application allows missing persons records to be generated, and 
notes to be attached to those records. Each message generated by 
the application contains the record and a set of all notes related to 
the record known by the sender. The application summary view is 
generated from the person records. There may be multiple records 
for the same person, in which case each one is listed separately. 
Notes attached to a person are displayed in the detailed view, which 
is generated by the message presentation transformation. Adding a 
new note for an existing record is done through the reply transfor¬ 
mation, which gets the original record (and notes) as a parameter. 
This transformation appends the new note to the existing ones, and 

^https://google.org/personfinder/global/home.html 
























generates a new aggregate message with the record and all known 
notes. A brand new missing person record is generated through the 
new transformation. Figure shows the native PeopleFinder, and 
its framework version. 

6.2 other applications 

GuerrillaPics is the SCAMPI photo sharing application. Since 
its messages have no dependencies between them (e.g., there are 
no replies or groupings), this is the simplest use-case for the frame¬ 
work. First, an application presenter transformation is used to gen¬ 
erate a grid of photo thumbnails. The transformation calls the mes¬ 
sage summary for each message to generate a thumbnail and to get 
the creation timestamp. These summary elements are then listed in 
a grid based on time ordering and displayed to the users through 
the framework. If a user selects one of the summaries by clicking 
the thumbnail, the message presentation transformation is used to 
generate a full resolution view. Finally, the application has also the 
ability to share a new photo through the framework by means of 
the new transformation. Figure [^illustrates comparison between 
native GuerrillaPics, and its framework version. 

GuerrillaTags is a message board application where messages 
are not independent as the photos in the previous case, but rather 
exist in the context of a topic {tag). In this case, the summary 
view is composed from all the unique tags contained in all the mes¬ 
sages that belong to the application. This is done by the application 
presenter transformation, which: 1) applies the message summary 
transformation to all the application messages and 2) filters out du¬ 
plicates from the produced list of tags to the list of available topics 
(each unique topic is a summary item). Each topic has its own state 
entry, which contains the set of messages with the common tag. 
The presentation view is per-topic, and lists all messages belonging 
to the given topic. It is generated by another presenter transforma¬ 
tion by applying the message presentation transformation on all the 
relevant messages (as determined from the previously saved topic 
state), and sorting the resulting list by creation timestamp. This 
demonstrates how complex application level logic can use the ap¬ 
plication transformations to generate complex presentation views. 
The application also allows to post messages via the framework by 
using the new transformation. 

All IBR-DTN applications use unicast communication model. 
Since the framework currently does not support this communica¬ 
tion model (recall Section [T^ , we have modified these applications 
to use the group communication model. 

Whisper is an opportunistic network chat application in which 
exchange text messages within a group of devices. Thus, the mes¬ 
saging model and application logic are identical to the Guerril¬ 
laTags application with the group of devices identifier (group ID) 
playing the role of the GuerrillaTags’s topic. Whisper includes ad¬ 
ditionally the functionality of responding to the current chat discus¬ 
sion through the framework via the reply transformation. 

Talkie is an opportunistic network walkie-talkie voice applica¬ 
tion in which users share voice messages with a group of devices. 
The messaging model and transformations logic for the message 
presentation are identical to Whisper’s use case (only chat message 
is replaced by voice). To generate a new message (or respond to 
existing conversation). Talkie uses new and reply transformations. 
They use the Media Capture API for recording the audio mes- 
sages0 

ShareBox is an opportunistic network file sharing application in 
which users exchange pictures or other files within the given group 
of devices. Since its messages have no dependencies between them. 


^^Not currently supported by Safari and Internet Explorer. 


Application 

Native message size 

Framework overhead 

Text messaging 

350 B 

16 KB 

Photo sharing 

65-120 KB 

7 KB 

PeopleFinder 

2 KB 

28 KB 


Table 3: Overhead introduced by the framework. 


the messaging model and transformations logic is similar to the 
GuerrillaPics app. The application summary view shows a table of 
message summary views for all Sharebox messages. The message 
summary view shows the size of the message together with the de¬ 
vice identifier of its sender and the timestamp. Einally, if the user 
selects a particular message, the message presentation transforma¬ 
tion shows the actual files carried inside the message. 

7. VALIDATION 

Our framework offers, in principle, content access to web users 
(in addition to native app users). To achieve this, the framework re¬ 
quires code to be shipped along with message state updates, which 
incurs overhead. In the following, we first evaluate the overhead 
and its impact. We then turn our attention to how many web nodes 
could be reached by content if those nodes choose to look at mes¬ 
sages. 

A related question is if web users moving between access points 
would also contribute to the connectivity of a disconnected ICN. 
We have shown that they can make a difference if the Liberouter 
nodes instrument the web storage of mobile browsers for relaying 
messages p5) . 

7.1 Overhead 

To evaluate overhead, we measure the actual message sizes of 
our implementation for three applications with sample contents. 
The results are shown in table [^: When using a text messaging 
application with tiny content, the message size grows almost 50- 
fold. However, this is only due to the small size of the native mes¬ 
sages. If the content size of the application messages increases, the 
overhead becomes more reasonable. Eor photo sharing, with small 
photo size of 65-120 KB, including the framework code adds just 
5-10% overhead. Eor the most sophisticated application we looked 
at, PeopleEinder, the overhead is roughly factor 15. 

Obviously, the code added via the framework is a function of the 
complexity of the code required to interpret, render, and construct 
messages: simpler applications will need less code. The overhead 
is obviously also a function of the content size so that more elabo¬ 
rate content will cause, even if more complex code is needed, lim¬ 
ited overhead only. One can argue that trends in web site complex¬ 
ity and siz^ show that increasing amounts of effort are put into 
conveying probably roughly the same amount of content. Thus, 
adding more sophisticated interaction framework code for a better 
experience would just mirror what is already done on the web. 

Eor disconnected ICNs exploiting opportunistic encounters of 
mobile nodes, the most important question is if and how the larger 
message sizes affect message delivery performance. To this end, 
we carried out simulations using the ONE simulator ( 27 ) with two 
different mobility models: 1) SPMBM: Shortest Path Map-Based 
Movement between waypoints chosen from the Helsinki downtown 
map (4.5x3.4km^) for 50, 100 and 200 pedestrians moving 
with speeds v = f/(0.5,1.5) m/s without predefined points of in¬ 
terest. 2) Same as 1 but additionally we introduce 10, 65 and 325 
static access points. 3) SMOOTH: a simple way to model human 
walks with the map from KAIST scenario (10 x 18km^) and 50 

^ ^ www.websiteoptimization.com/speed/tweak/average-web-page/ 
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(a) GuerrillaPics 


(b) PeopleFinder 


Figure 8: Comparison of native and web-based user interface for: a) GuerrillaPics, b) PeopleFinder apps. 
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Figure 9: Impact of the overhead introduced by the framework 
(reflected in different message sizes) on the coverage for messag¬ 
ing (top) and photo sharing (bottom) with all three loads for the 
SPMBM model. 


nodes. SMOOTH is a synthetic model but it is based on real traces 
and captures most of the properties of human mobility. Our nodes 
communicate at a net bit rate of 2 Mbit/s with a radio range of 50 m. 
The nodes use simple epidemic routing p6) . We choose a random 
node to generate a new message every 12 s, 60 s, and 300 s, referred 
to as high, medium, and low load, respectively. Messages expire 
after 5400 s. The message sizes correspond to those for native and 
framework-enhanced messages for the text and photo sharing ap¬ 
plications to pick two extremes. We measure the fraction of nodes 
that obtain a copy of each message, termed coverage, and plot the 
average of 10 simulation runs, each lasting for 12 hours. 

As shown in Figurej^ we find that the overhead of the framework 
does not notably impact the performance results. The coverage re¬ 
mains the same both for using native application messaging and 
for the framework-enhanced messaging for the text chat applica¬ 
tion (top) as well as for photo sharing (bottom). For the SMOOTH 
mobility model we obtain similar results just with much lower cov¬ 
erage rate due to sparser node distribution. This indicates that in 
the realistic parameter range, the system is not bottlenecked by the 


contact capacity, and therefore the added messaging overhead does 
not negatively impact the message distribution. 

Further, a maximum message rate limit was also observed in past 
experiments, which have shown that the per-message overhead of 
protocol implementations appears to be more dominant in commu¬ 
nication performance than the per-byte overhead. This was, for 
example, found in a comparison of three different DTN bundle 
protocol implementations p^ , particularly for growing the pay- 
load size from 10 bytes to 10 KB and beyond. Our own (not yet 
statistically significant) experiments seem to confirm this. While 
implementation details play one important role here, there are also 
systematic aspects to consider: nodes that meet need to exchange 
vectors which messages they have, decide which ones to replicate, 
and then perform a forwarding process for each message, which 
causes per-message overhead. Researchers also found that neigh¬ 
bor discovering and pairing with peers is expensive and takes easily 
tens of seconds while a 20 KB data transfer takes only 160 ms 
even assuming just 1 Mbit/s data rate. We therefore argue that the 
framework overhead is not of substantial importance in practice. 

7.2 Content Reach 

The previous subsection suggests that the overhead introduced 
by our framework won’t degrade performance for native nodes. But 
how well does the framework allow reaching out to web nodes? We 
conduct further simulations to answer this question, using largely 
the same setup as above. In addition, we introduce two further 
classes of nodes: access point nodes that, besides running the ICN 
middleware protocols, also serve as WLAN access points and run 
the server side of the interaction framework (cf. Figure]^. And 
web nodes that only interact with these access point nodes, but nei¬ 
ther with each other nor with regular DTN nodes. We choose the 
number of web nodes to be equal (LI), five-fold (L5), or ten-fold 
(LIO) the number of DTN nodes. 

Obviously, how many web nodes we can reach will depend on 
the movement patterns of those nodes and where the access point 
nodes are located, and how they move. However, our simulation 
results shown in Figure hint that we can notably increase the 
visibility of content generated by native applications; without the 
web framework this content would not be accessible by web nodes. 
For the SPMBM scenario, we find that the content coverage may 
come close to that of the native nodes and reach close to 40% of the 
web nodes. Additionally deploying 10 static access points brings 
it up to 50%. Comparing this to Figure content availability is 
roughly equal for native and web nodes. Note that, the fraction of 
web nodes reached gets bigger as their number increases from LI 
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Figure 10: Coverage achieved for 50, 250 and 500 web nodes for 
the SPMBM model with 50 native nodes of which 25 are moving 
access points with medium load for text messaging (top) and photo 
sharing (bottom). 


to L5 to LIO, so the absolute number of additional nodes reached 
grows even more. We obtain similar findings for high (up to 40%) 
and low loads (up to 50%) for both text and photo applications. 
The SMOOTH scenario yields a qualitatively similar picture, again 
at much lower performance. Results of our simulations with 100 
and 200 native nodes for all scenarios are also in line with these 
findings. 

8. RELATED WORK 

Our framework borrows concepts from different fields of related 
work to create a unique combination. Most important is the con¬ 
cept of embedding programs into messages and executing them in 
network nodes, discussed in the past as active networking | [5^ and 
mobile code. Lee et al. p8) present a a node architecture allow¬ 
ing to deploy in-network services in a next generation Internet. Its 
main contribution is the concept of making the core network be¬ 
come a distributed service execution environment. It also describes 
an architecture for extensible router allowing for implementing new 
router features. Similar concepts of extensible router architecture 
can be also seen in works of Router Plugin s fTT| , LARA-h-i- 46 , 
PromethOS (41), Pronto (T^ and SARA (^ SOFTNET 
PLAN (Tl| , Bowman and CANEs (D are examples of active net¬ 
working systems that assume network packets to contain programs, 
which are used to manage network nodes. All these systems con¬ 
centrate on executing code inside the network in order to improve 
network capabilities, while our solution takes advantage of trans¬ 
formation execution to enable content access to legacy users. More¬ 
over, active networks focus on individual (small) packets, thus lim¬ 
iting the amount of code that can be carried, while our message- 
based system is not limited by MTU size. 

Baldi et al. i4| and Thorn study the applicability of pro¬ 
gramming languages in mobile code. Ghezzi et al. fTS) describe 
architectures of mobile code applications. Our framework choose 
one specific programming language and a specific application de¬ 
sign tailored to the purpose of read and write access to opportunistic 
message contents. 


Security aspects of mobile code are covered by Arden et al. p^ . 
He introduces a new architecture for secure mobile code that de¬ 
velopers can use, publish and share mobile code securely across 
trusted domains. Older work presenting security aspects of mobile 
code are Rubin et al. | [44) , Zachary [5^ and Brooks | [43l . Kosta 
et al. 145) present the concept of using mobile code for improving 
code execution on mobile devices by offloading part of code execu¬ 
tion to the cloud. Similar work by Simanta et al. | [50) describe an ar¬ 
chitecture for offloading mobile code execution in hostile network 
environments. Unlike these works, our system uses mobile code 
as a tool for message content presentation and our main concern is 
offering an isolated execution environment for the application code 
so that the code does not harm the node running it (which is quite 
similar to the concerns of protecting routers in Active Networks). 

Another set of related work concerns document presentation tech¬ 
niques. MINOS 0 was an early system allowing for presentation 
of multimedia content embedded in a document. Boguraev et al. 
presents usage of linguistic analysis tools for generation of text doc¬ 
ument description and its visualization. Our solution is not limited 
to content presentation, but offers a full-fiedged interaction to the 
web user. 

Douceur et al. GD shows an alternative approach for using na¬ 
tive applications in the web browser by the legacy device users. 
This system requires web servers to have an (application-specific) 
gateway installed that translates a native app into a web app. On the 
other hand, our framework is more fiexible, as it carries all trans¬ 
formation code inside the messages themselves so that no node re¬ 
quires prior knowledge of specific applications. 

9. CONCLUSION 

In this paper, we have presented an ICN based system design 
for enabling modern web applications (i.e., interactive applications 
that run in a web browser context) to be developed for and deployed 
in disconnected networks. Our design is based on the idea of dis¬ 
tributing small, self-contained pieces of application content directly 
in the network, rather than sending it to a centralized database, and 
bundling the presentation and interaction logic as code together 
with the message. This approach enables browser-based interac¬ 
tions in scenarios without a well-connected infrastructure network. 

Beyond the design of our system, we showed and evaluated the 
practicality of our approach through a prototype implementation 
on our Liberouter platform. We showed generality of the approach 
by running our framework on two different disconnected network¬ 
ing platforms, SCAMPI and IBR-DTN. Further, we demonstrated 
how to apply our design to multiple native applications to produce 
an interactive web versions of them. Finally, we showed through 
simulations that the overhead imposed by our design is low enough 
that it does not have a significant negative impact on the message 
dissemination by the underlying networking platform. 

There are a number of open issues to be addressed in our fu¬ 
ture work. This includes enhancing security and privacy function¬ 
ality of the framework by enabling access to encrypted content for 
web users and allow the implementation of closed communication 
groups. One special case of closed groups will be embracing web 
users also for the point-to-point (user-to-user) unicast communica¬ 
tion. Finally, we are exploring how to exploit web browser capabil¬ 
ities for establishing direct browser-to-browser communication for 
web users without a mediating entity (such as an access point). 

The framework and simulation source codes are available at 
http://www.netlab.tkk.fi/tutkimus/dtn/legacy-app-framework/ 
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